隐藏的语言内核
Rust 有一个秘密：它实际上 两种语言合而为一。虽然安全 Rust 是你的守护者，但 Rust 编译器本质上是 保守的。它遵循一种严格的哲学：宁可拒绝一个合法且安全的程序，也不愿意外允许一个危险的程序。这在硬件能力与编译器可证明的范围之间留下了一道鸿沟。
严格的现实
想象编译器是一位严格的守门人。在我们的代码示例中，匹配守卫 if y 适用于整个模式组 (4 | 5 | 6)。这种严格的 优先级 反映了借用检查器的工作方式：它对内存施加全局且不容妥协的规则。但底层的计算机硬件本身是 固有的不安全；它并不理解所有权或生命周期的概念。要构建像 split_at_mut这样的高性能工具，我们必须进入 不安全 Rust ‘逃生通道’，执行那些技术上正确但逻辑上过于复杂、超出编译器静态分析能力的操作。
红色与绿色圆圈之间的差距正是不安全 Rust 的存在空间——当静态分析失效时，它使我们能够充分挖掘硬件的全部潜力。
main.py
TERMINALbash — 80x24
> Ready. Click "Run" to execute.
>
QUESTION 1
What is the primary reason for the existence of Unsafe Rust?
To allow programmers to write C code in Rust.
Because static analysis is conservative and may reject valid code.
To disable the borrow checker entirely for the whole project.
Because hardware is naturally safe and doesn't need checks.
✅ Correct!
The compiler prefers false positives (rejecting safe code) over false negatives (accepting unsafe code).❌ Incorrect
Unsafe Rust is a controlled 'escape hatch' specifically for when the compiler's proof-engine is too limited.QUESTION 2
In the pattern
4 | 5 | 6 if y, what does the guard if y apply to?Only the value 6.
Only the values 5 and 6.
The entire pattern group (4, 5, and 6).
It depends on the value of x.
✅ Correct!
Match guards have lower precedence than the 'or' operator in patterns.❌ Incorrect
The guard acts on the combined group (4 | 5 | 6).QUESTION 3
Does Unsafe Rust turn off the borrow checker?
Yes, it disables all safety checks within the block.
No, it only provides 'superpowers' like raw pointer dereferencing.
Yes, but only for variables declared inside the block.
No, it actually makes the borrow checker stricter.
✅ Correct!
The borrow checker is still active; unsafe blocks just let you perform specific actions it otherwise forbids.❌ Incorrect
Common misconception! Unsafe blocks only grant specific capabilities like dereferencing raw pointers.QUESTION 4
Why is computer hardware considered 'inherently unsafe'?
It lacks the ability to execute instructions.
It does not understand Rust's ownership and lifetime rules.
Hardware is prone to physical failure.
Hardware requires a garbage collector to function.
✅ Correct!
Hardware works with raw addresses and registers; it has no concept of 'borrowing' or 'safety'.❌ Incorrect
The issue is the abstraction gap: hardware deals with bits and addresses, not Rust's safety guarantees.QUESTION 5
Which scenario necessitates an unsafe block?
Sorting a vector of integers.
Splitting a mutable slice into two non-overlapping parts.
Creating a new HashMap.
Using a match statement with a guard.
✅ Correct!
The compiler cannot prove that the two resulting slices won't overlap, even if the logic is correct.❌ Incorrect
Standard collections and sorting use safe Rust (or wrap unsafe code in safe APIs for you).Unsafe Logic & Safe Wrappers
Bridging the gap between Proof and Reality
You are implementing a performance-critical buffer that requires raw memory access to interact with a hardware I/O port. The compiler rejects your code because it involves aliasing pointers that it cannot verify as safe.
Q
Explain why it is standard practice to wrap 'unsafe' code in a safe function.
Solution:
By wrapping unsafe code in a safe function, we encapsulate the risk. The developer manually verifies the invariants (like bounds checking), allowing users of the API to benefit from the performance of unsafe code without having to use 'unsafe' blocks themselves.
By wrapping unsafe code in a safe function, we encapsulate the risk. The developer manually verifies the invariants (like bounds checking), allowing users of the API to benefit from the performance of unsafe code without having to use 'unsafe' blocks themselves.
Q
In the context of the 'split_at_mut' example, what is the 'contract' the developer must fulfill?
Solution:
The developer must ensure that the two resulting mutable slices truly do not overlap in memory. If they do overlap, it would cause data races or undefined behavior, which 'unsafe' allows but the developer must prevent.
The developer must ensure that the two resulting mutable slices truly do not overlap in memory. If they do overlap, it would cause data races or undefined behavior, which 'unsafe' allows but the developer must prevent.